System and method for sending, delivery and receiving of digital content

ABSTRACT

Embodiments of a content delivery system are disclosed herein. In particular, an embodiment of a content delivery system may receive content associated with a first destination identifier associated with a first delivery method, determine a second destination identifier and a second delivery method associated with the first delivery destination, and deliver the content to the second destination identifier according to the second delivery method.

RELATED APPLICATIONS

This application claims a benefit of priority under 35 U.S.C. 119 toU.S. Provisional Patent Application Ser. No. 61/664,435, filed Jun. 26,2012, entitled “SYSTEM AND METHOD FOR SENDING, DELIVERY AND RECEIVING OFDIGITAL CONTENT,” by inventors Brian Lennstrom and Lyle Bush, which isincorporated herein in its entirety by reference.

TECHNICAL FIELD

This disclosure relates generally to digital content delivery in anetwork environment. More particularly, this disclosure relates to thetransmission, delivery or reception of digital content through computernetworks or telephone networks. Even more specifically, this disclosurerelates to the secure transmission, delivery or reception of digitalcontent over networks using distributed services.

BACKGROUND

With the increase of networked (both wired and wireless) and distributedcomputing environments (e.g., the Internet, mobile or cellular networks,office internets or intranets, etc.) the need to transfer digitalcontent between computing devices has increased markedly. Commensuratewith the increased need to transfer this digital content, the size ofthe data that it is desired to transfer has also increased. Thiscombination of factors presents difficulties with respect to thesending, delivery and reception of such digital content.

One way of sending such digital content is using facsimile. A facsimile(fax) comprises a document in a digital image format. The document isassociated with metadata that specifies a destination with respect tothe publicly switched telephone network (PSTN). Thus, typically for atleast a portion of the transmission, the document is transmitted overthe PSTN. Faxing provides a secure, traceable and non-repudiablemechanism for content delivery and can be particularly useful inbusiness environments.

Faxing, however, has limitations. For example, conventional fax machinescan only transmit black and white files with limited resolution in aspecific format such as the Tagged Image File Format (TIFF). In manycases, people wish to transmit digital content in other formats,including for example, .jpg or .pdf. Faxing systems may not allow thetransmission or attachment of these types of digital content.

While digital content may currently be sent between users the methodsfor doing so do not meet the need for a secure, traceable ornon-repudiable method for sending digital content as is currentlydesired. What is desired, then, are versatile systems and methods forthe sending, delivery and reception of digital content.

SUMMARY

Embodiments of systems and methods for the sending, delivery andreceiving of digital content are disclosed herein. In particular,certain embodiments include a sending connector that may be deployed ata user's site, and a content delivery system that may be deployedremotely from the user's site. The sending connector can be accessed atthe user's site over a network in order to perform functions associatedwith sending digital content. The sending connector deployed at theuser's site communicates with the remotely deployed content deliverysystem to send, obtain status on, or perform other functions associatedwith, the delivery of digital content.

In certain embodiments, the content delivery system may include anadministration module by which recipients may register destinationidentifiers (such as, without limitation, email addresses, fax numbers,URLs, network locations, etc.) and a delivery method or deliverydestination associated with the destination identifier. The contentdelivery system may thus receive digital content from a sender, wherethe sender intends delivery by a particular delivery method and wherethe sender used a particular destination identifier associated with theintended delivery method. The content delivery system can deliver thedigital content to the recipient using an appropriate delivery method,or to an appropriate delivery destination (e.g., a delivery method ordelivery destination specified by the recipient). Such a contentdelivery system may be agnostic to the format of such digital content,delivering such content without respect to the format of such digitalcontent.

Thus, using embodiments of such a content delivery system, digitalcontent may be delivered to a recipient in its original format using adelivery method or delivery destination desired by the recipientirrespective of the delivery method intended by the sender. Accordingly,such content may be immediately processed or utilized by the recipient,especially when the recipient includes a computing application ordestination (e.g., SharePoint library, Oracle, SAP, etc.). Similarly, assuch content is received in its original format it may be usedsubstantially without modification by a consuming application or otheruser and thus may immediately be integrated into existing workflows ofthe recipient or may be used to initiate such workflows or initiateparticular steps in a workflow.

Furthermore, in some cases, the content delivery system may providemetadata to a recipient regarding digital content intended for thatrecipient. This metadata may be provided in addition to, or in lieu of,the digital content itself. In such cases, the metadata of such digitalcontent may be utilized to initiate such processing, workflows or stepsregardless of whether such digital content is eventually delivered tothe recipient or not.

Additionally, security of the sending and delivery of digital contentmay be increased by verifying destination data such as delivery methodsor delivery destinations using a registration system, encryptingtransmissions over the network (e.g., using Basic 256 or being X.509compliant) and deleting digital content after the expiration of acertain time period. Thus, by implementing a content delivery system ina central locale such that digital content only passes through a singleintermediary during delivery and ensuring that content is deleted fromthis central location after delivery, or after expiration of a timeperiod, security may be enhanced. Traceability may also be implementedthrough the use of reporting features provided by embodiments of sendingconnectors or content delivery systems as disclosed herein.

Moreover, as embodiments here may be usefully utilized by computingsystems or users to send digital content and may deliver such digitalcontent to both computing systems and users, embodiments of thesecontent delivery systems may be used to deliver digital content in auser to user context, a system to user context, a user to system contextor a system to system context. Thus, embodiments as described may beusefully employed, and integrated, with on premise applications.

In one embodiment, a method for delivering content may include receivingcontent associated with a first destination identifier associated with afirst delivery method, determining a second destination identifier and asecond delivery method associated with the first delivery destinationand delivering the content to the second destination identifieraccording to the second delivery method.

In some embodiments, the sender module and the forwarder module are in acloud based computing environment and the content is received at thesender module from a sending connector at a sending device. The sendingconnector may, for example, be a plug-in of an application.

As used herein throughout, cloud based computing refers to utilizationof a network of distributed servers. In some embodiments, cloudcomputing is further defined by a network of distributed servers underthe control of an organization on behalf of a set of users and/orclients who may access one or more of a set of software and hardwareservices executing on the servers remotely. In some instances still, theorganization is an external organization independent of the users and/orclients.

In a particular embodiment, a remote content access module may beconfigured to allow a user to access the content at a location andwherein delivering content comprises providing the location from whichthe content may be accessed and sending the location to the seconddestination identifier. The second destination identifier may be thesame as the first destination identifier or the second delivery methodmay be the same as the first delivery method.

These, and other, aspects of the invention will be better appreciatedand understood when considered in conjunction with the followingdescription and the accompanying drawings. The following description,while indicating various embodiments of the invention and numerousspecific details thereof, is given by way of illustration and not oflimitation. Many substitutions, modifications, additions orrearrangements may be made within the scope of the invention, and theinvention includes all such substitutions, modifications, additions orrearrangements.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings accompanying and forming part of this specification areincluded to depict certain aspects of the invention. A clearerimpression of the invention, and of the components and operation ofsystems provided with the invention, will become more readily apparentby referring to the exemplary, and therefore nonlimiting, embodimentsillustrated in the drawings, wherein identical reference numeralsdesignate the same components. Note that the features illustrated in thedrawings are not necessarily drawn to scale.

FIG. 1 depicts one embodiment of an architecture for a content deliverysystem.

FIG. 2 depicts one embodiment of an architecture for a content deliverysystem.

FIGS. 3A-3E depict one embodiment or a method for sending digitalcontent.

FIG. 4 depicts one embodiment of a transaction system.

FIG. 5 depicts one embodiment of a transaction system.

FIG. 6 depicts one embodiment of an interface.

FIG. 7 depicts one embodiment of an interface.

FIG. 8 depicts one embodiment of an interface.

FIG. 9 depicts one embodiment of an interface.

FIG. 10 depicts one embodiment of an interface.

DETAILED DESCRIPTION

The invention and the various features and advantageous details thereofare explained more fully with reference to the nonlimiting embodimentsthat are illustrated in the accompanying drawings and detailed in thefollowing description. Descriptions of well-known starting materials,processing techniques, components and equipment are omitted so as not tounnecessarily obscure the invention in detail. It should be understood,however, that the detailed description and the specific examples, whileindicating preferred embodiments of the invention, are given by way ofillustration only and not by way of limitation. Various substitutions,modifications, additions and/or rearrangements within the spirit and/orscope of the underlying inventive concept will become apparent to thoseskilled in the art from this disclosure. Embodiments discussed hereincan be implemented in suitable computer-executable instructions that mayreside on a computer readable medium (e.g., a hard disk (HD)), hardwarecircuitry or the like, or any combination.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,article, or apparatus that comprises a list of elements is notnecessarily limited only those elements but may include other elementsnot expressly listed or inherent to such process, product, article, orapparatus. Further, unless expressly stated to the contrary, “or” refersto an inclusive or and not to an exclusive or. For example, a conditionA or B is satisfied by any one of the following: A is true (or present)and B is false (or not present), A is false (or not present) and B istrue (or present), and both A and B are true (or present).

Additionally, any examples or illustrations given herein are not to beregarded in any way as restrictions on, limits to, or expressdefinitions of, any term or terms with which they are utilized. Instead,these examples or illustrations are to be regarded as being describedwith respect to one particular embodiment and as illustrative only.Those of ordinary skill in the art will appreciate that any term orterms with which these examples or illustrations are utilized willencompass other embodiments which may or may not be given therewith orelsewhere in the specification and all such embodiments are intended tobe included within the scope of that term or terms. Language designatingsuch nonlimiting examples and illustrations includes, but is not limitedto: “for example,” “for instance,” “e.g.,” “in one embodiment.”

Embodiments of the present invention can be implemented in a computercommunicatively coupled to a network (for example, the Internet, anintranet, an internet, a WAN, a LAN, a SAN, etc.), another computer, orin a standalone computer. As is known to those skilled in the art, thecomputer can include a central processing unit (“CPU”) or processor, atleast one read-only memory (“ROM”), at least one random access memory(“RAM”), at least one hard drive (“HD”), and one or more input/output(“I/O”) device(s). The I/O devices can include a keyboard, monitor,printer, electronic pointing device (for example, mouse, trackball,stylus, etc.), or the like. In certain embodiments, the computer hasaccess to at least one database over the network.

ROM, RAM, and HD are computer memories for storing computer-executableinstructions executable by the CPU or capable of being compiled orinterpreted to be executable by the CPU. Within this disclosure, theterm “computer readable medium” is not limited to ROM, RAM, and HD andcan include any type of data storage medium that can be read by aprocessor. For example, a computer-readable medium may refer to a datacartridge, a data backup magnetic tape, a floppy diskette, a flashmemory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, orthe like. The processes described herein may be implemented in suitablecomputer-executable instructions that may reside on a computer readablemedium (for example, a disk, CD-ROM, a memory, etc.). Alternatively, thecomputer-executable instructions may be stored as software codecomponents on a DASD array, magnetic tape, floppy diskette, opticalstorage device, or other appropriate computer-readable medium or storagedevice.

In one exemplary embodiment of the invention, the computer-executableinstructions may be lines of C++, Java, JavaScript, HTML, or any otherprogramming or scripting code. Other software/hardware/networkarchitectures may be used. For example, the functions of embodiments maybe implemented on one computer or shared or distributed among two ormore computers across a network. In one embodiment, the functions ofembodiments may be distributed in the network. Communications betweencomputers implementing embodiments of the invention can be accomplishedusing any electronic, optical, ratio frequency signals, or othersuitable methods and tools of communication in compliance with networkprotocols.

Communications between computers implementing embodiments can beaccomplished using any electronic, optical, radio frequency signals, orother suitable methods and tools of communication in compliance withknown network protocols. It will be understood for purposes of thisdisclosure that a service or module is one or more computer devices,configured (e.g., by a computer process or hardware) to perform one ormore functions. A service may present one or more interfaces which canbe utilized to access these functions. Such interfaces include APIs,interfaces presented for a web services, web pages, remote procedurecalls, remote method invocation, etc.

Before discussing specific embodiments a brief overview of the contextof the disclosure may be helpful. With the increase of networked (bothwired and wireless) and distributed computing environments (e.g., theInternet, mobile or cellular networks, office internets or intranets,etc.) the need to transfer digital content between computing devices hasincreased markedly. Commensurate with the increased need to transferthis digital content, the size of the data that it is desired totransfer has also increased. This combination of factors, among others,presents difficulties with respect to the sending, delivery andreception of such digital content.

One way of sending such digital content is using facsimile. A facsimile(fax) comprises a document in a digital image format. The document isassociated with metadata that specifies a destination with respect tothe publicly switched telephone network (PSTN). Thus, typically for atleast a portion of the transmission, the document is transmitted overthe PSTN. Faxing provides a secure, traceable and non-repudiablemechanism for content delivery and can be particularly useful inbusiness environments.

Faxing, however, has limitations. For example, conventional fax machinescan only transmit black and white files with limited resolution in aspecific format such as the Tagged Image File Format (TIFF). Further,the transmission speed can be very slow compared to today's Internetbased standards. Not surprisingly, in recent years traditional faxingtechnology has faced increasing competition from Internet Protocol (IP)network (e.g., Internet, LANs, WANs, intranets, extranets, etc.) basedalternatives (generally referred to as Internet faxing).

For example, instead of standalone fax machines, fax servers may beutilized in enterprise network environments. Typically, a fax server isa server computer having the necessary fax software and hardware toreceive and send faxes over IP networks. Using fax servers may reducethe cost of transmission since there is no telephone connection chargewhen sending a fax over the Internet.

Additionally, some faxing solutions may be problematic as they includethe need to access fax modems, routers or the PSTN (e.g., telephonelines) at the user's physical location. Increasingly, however, in mostother areas of communication, including telephony itself, the trend hasbeen toward use of the IP network based protocols (e.g., SMTP, FTP,VoIP, etc.). Accordingly, many traditional fax users no longer wish tomaintain telephone lines or other access to the PSTN. It would thereforebe desirable to give these users the ability to continue sending andreceiving faxes without having to maintain local access to the PSTN.

Moreover, and importantly, in many cases fax documents are transmittedin a particular format (e.g., TIFF). In many cases, people wish totransmit digital content in other formats, including for example, .jpgor .pdf. Faxing systems may not allow the transmission or attachment ofthese types of digital content.

Digital content may also be transmitted using a wide variety of methodsthat utilize a computer based network (referred to hereinafter as anetwork) such as the Internet. While these network-based methods for thesending, delivery and reception of digital content are somewhatversatile, they are not without drawbacks. One challenge is that theInternet carries a vast range of information resources and services overa hodge-podge of protocols. For example, a user may send an email overthe Internet, upload a file to a network site, and make a phone callover the Internet. The email may be sent via the Simple Mail transferProtocol (SMTP), the file may be uploaded via the File Transfer Protocol(FTP), and the phone call may be conducted using the Voice over InternetProtocol (VoIP). Many of these existing network protocols do not meetthe secure, traceable and non-repudiable needs of today's businesses.For example, the email (along with any attachment) as well as the filesent over the Internet unencrypted can be vulnerable to interception.

Thus, what is desired are systems and methods for the sending, deliveryand reception of digital content that provide at least some of thesecure, traceable and non-repudiable features of faxing with theversatility of network based methods for the sending, delivery andreception of digital content.

To that end, attention is now directed toward the embodiments of systemsand methods for the sending, delivery and receiving of digital contentdisclosed herein. In particular, certain embodiments include a sendingconnector that may be deployed at a user's site, and a content deliverysystem that may be deployed remotely from the user's site. The sendingconnector can be accessed at the user's site in order to performfunctions associated with sending digital content or obtaining status ondigital content that was sent. The sending connector deployed at theuser's site communicates with the remotely deployed content deliverysystem to send, obtain status on, or perform other functions associatedwith, the delivery of digital content.

The content delivery system may include an administration module bywhich recipients may register destination identifiers (such as, withoutlimitation, email addresses, fax numbers, URLs, network locations, etc.)and a delivery method or delivery destination associated with thedestination identifier. The content delivery system may thus receivedigital content from a sender, where the sender intends delivery by aparticular delivery method and where the sender used a particulardestination identifier associated with the intended delivery method. Thecontent delivery system can deliver the digital content to the recipientusing an appropriate delivery method or to an appropriate deliverydestination (e.g., a delivery method or delivery destination specifiedby the recipient, which may, or may not, be the same as the deliverydestination of delivery method used by the sender). Such a contentdelivery system may be agnostic to the format of such digital content,delivering such content without respect to the format of such digitalcontent.

Thus, using embodiments of such a content delivery system, digitalcontent may be delivered to a recipient in its original format using adelivery method or delivery destination desired by the recipientirrespective of the delivery method intended by the sender. Accordingly,such content may be immediately processed or utilized by the recipient,including in cases where the recipient includes a computing applicationor destination (e.g., SharePoint library, Oracle, SAP, etc.). Similarly,as such content is received in its original format it may immediatelyintegrated into existing workflows of the recipient or may be used toinitiate such workflows or initiate particular steps in a workflow.

Furthermore, in some cases, the content delivery system may providemetadata to the recipient regarding digital content. This metadata maybe provided in addition to, or in lieu of, the digital content itself.In such cases, the metadata of such digital content may be utilized toinitiate such processing, workflows or steps regardless of whether suchdigital content is eventually delivered to the recipient or not.

Additionally, security of the sending and delivery of digital contentmay be increased by verifying destination data such as delivery methodsor delivery destinations using a registration system, encryptingtransmissions over the network (e.g., using Basic 256 or being X.509compliant) and deleting digital content after the expiration of acertain time period. Thus, by implementing a content delivery system ina central locale such that digital content only passes through a singleintermediary during delivery and ensuring that content is deleted fromthis central location after delivery, or after expiration of a timeperiod, security may be enhanced. Traceability may also be implementedthrough the use of reporting features provided by embodiments of sendingconnectors or content delivery systems as disclosed herein.

Moreover, as embodiments here may be usefully utilized by computingsystems or users to send digital content and may deliver such digitalcontent to both computing systems and users; embodiments of thesecontent delivery systems may be used to deliver digital content in auser to user context, a system (e.g., application) to user context, auser to system context or a system to system context.

Turning now to FIG. 1, one embodiment of an architecture for digitalcontent delivery is depicted. Digital content delivery architecture 100includes content sender systems 140 (e.g., one or more computing devicesincluding mobile computing devices such as laptops, smartphones,personal data assistants, etc.) and content delivery system 130(including data store 136) communicating over network 110 which may be,for example, the Internet, an internet, an intranet, a LAN a WAN, an IPbased network, etc. These communications may be accomplished accordingto one or more protocols such as, for example, HTTP or SOAP and in oneor more formats such as, for example, XML or HTML and may be encryptedusing for example a public private key pair, Basic 256, adherence to theX.509 standard, etc.

Sending connectors 106 are installed or otherwise executed at a site ordevice where users wish to send digital content. Users in such anarchitecture 100 may be companies, individual users, or any other entitywishing to send digital content. Accordingly, sending connector 106 maybe one or more computing devices or one or more computer processesexecuting on one or more computer devices utilized by such users to senddigital content or may be a process executing in conjunction withanother computer process, such as a plug-in to an application or abrowser plug-in, a program executing in conjunction with a web page(e.g., an applet), etc.

Sending connector 106 may provide an interface such as an API, library,or other hardware or software interface through which digital content tosend may be received from a client 104 of the sending connector 106.These clients 104 may include an email client (e.g., Outlook),SharePoint, an Oracle application, an SAP application, Lotus Notes, afax machine, a web page loaded in a browser, a connector to SAP, anenterprise resource planning (ERP) system, etc.

In one embodiment, for example, the sending connector 106 may be aplug-in for use with an application such that when digital content issent using the application (e.g., an email with an attachment sentutilizing an email application) the communication including the digitalcontent may be received by the sending connector 106.

In another embodiment, the sending connector 106 may be a process suchas an applet, executing in conjunction with a web page loaded in abrowser, such that digital content may be sent using the web page andthe digital content may be received by the sending connector 106. In oneparticular embodiment, such a web page may be a web page that tracks aconversation between one or more senders or recipients of content, suchthat communications and digital content sent between the senders andrecipients may be tracked and presented over multiple communications.For example, such a web site or web page may be provided by contentdelivery system 130 such that when a browser at sending system 140accesses the web page, a module (e.g., such as an applet) may beexecuted by the browser in conjunction with accessing the web page. Thisapplet may be configured as sending connector 106 such that a userinteracting with the web may provide digital content to the sendingconnector 106.

In any event, once sending connector 106 receives digital content to besent, the sending connector 106 may communicate with content deliverysystem 130 over network 110 to send such digital content.

Content delivery system 130 includes administration module 134.Administration module 134 is configured to provide an interface by whichusers who wish to receive digital content may provide destination data.Such destination data may include, for example, a destination identifiersuch as an email address, a telephone number, a URL, an internetprotocol (IP) address, an identifier for a SharePoint repository, or anyother type of identifier that may be used (e.g., by senders) to specifya location to which digital content it to be sent.

Additionally, the destination data may include a delivery method ordelivery destination associated with the destination identifier. Forexample, in association with a destination identifier the user mayspecify a network based delivery method; a delivery method associatedwith a particular program such as SecureDocs by OpenText; a deliverymethod such as email and an associated delivery destination such as anemail address; a delivery method of an application such as SharePoint orOracle and a delivery destination such as a URL or other networklocation associated with a module associated with the application of thedelivery method; a delivery method of fax over PSTN and an associatedtelephone number as a delivery destination; a delivery method of pointto point delivery (P2P) and provide a network location associated with adestination where such a location is associated with a fax server, etc.

The destination data, including a destination identifier and associateddelivery method or delivery destination, may be stored in system table138 in data store 136. Thus, the system table 138 may comprise a set ofregistered destination identifiers and associated destination data. Itwill be noted here that users who wish to receive digital content mayspecify multiple destination identifiers and the same or differentdestination data associated with these multiple destination identifiers.Administration module 134 may also present an interface by which usersof content delivery system 130 may obtain or view statistics on digitalcontent sent or received such as data usage, status on delivery, etc.

Content delivery system 130 also includes a sender module 142, forwardermodule 144 and remote content access module 146. Sender module 142 isconfigured to receive digital content (e.g., from a sending connector106) associated with a destination identifier and store such digitalcontent 132 in the data store 136 in association with the destinationidentifier. Forwarder module 144 is configured to retrieve digitalcontent 132 from the data store 136 and deliver the digital content.Such delivery may be based on the presence, or contents, of destinationdata in system table 138 associated with the destination identifier.

Forwarder module 144 may be configured to deliver digital content tomultiple different receiving entities or may be associated with aspecific receiving entity (in which case there may be multiple forwardermodules 144). Additionally, it will be realized that while the forwardermodule 144 has been depicted in the content delivery system 130 in thisembodiment, in other embodiments such a forwarder 144 may reside at thesite of a receiving entity.

Accordingly, when a user in architecture 100 wishes to send digitalcontent he may utilize a client 104 at the user's site to send thedigital content using a destination identifier. In one embodiment, forexample, an interface may be presented by the client 104 which allowsthe user to specify that he would like digital content to be deliveredusing the content delivery system 130 or the client 104 may be a webbrowser displaying a page allowing a user to send digital content usingthe sender connector 106 (which may be being executed by the browser),etc.

The digital content and the destination identifier may thus be receivedby the sender connector 106. The sender connector 106 may then send thedestination identifier to the sender module 142 (e.g., using aninterface provided by the sender module 142). The sender module 142 mayauthenticate the destination identifier by accessing the system table138 to determine if the destination identifier has been registered by auser. Additionally, in some embodiments, the sender module 142 maydetermine if the sender has an entitlement to send the digital content(e.g., if the sender has an account, if the sender is allowed to use aspecified sending or delivery method, if the sender can send the desiredamount of data, etc.) by checking an account associated with the senderor sender connector 106.

If the sending of digital content by the sender to the destinationidentifier is authorized, a transmission identifier such as a token or aglobally unique identifier (GUID) or the like may be provided to thesending connector 106 (e.g., by sender module 142). The sendingconnector 106 may transmit the digital content to the sender module 142using this transmission identifier. In one embodiment, this digitalcontent may be transmitted from the sender connector 106 in a set ofchunks. Each of these chunks may comprise a portion of the digitalcontent. Moreover, the sending connector 106 may transmit metadataassociated with the digital content. This metadata may comprise an XMLfile that includes data on the digital content such as size, file type,or other types of data.

When the sender module 142 receives this digital content, the digitalcontent (and associated metadata if received) is stored in the datastore 136 in association with the transmission identifier and thedestination identifier. Forwarder module 144 can then be notified thatthere is digital content 132 in data store 136. The forwarder module 144may utilize the destination identifier associated with the digitalcontent 132 to determine the delivery method or delivery destinationassociated with the destination identifier. The forwarder module 144will deliver the digital content based on the delivery method ordelivery destination associated with the destination identifier or thepresence of data pertaining to such a delivery method or deliverydestination.

For example, if there is no delivery method or delivery destinationassociated with the destination identifier present, an error may bereturned to the sending connector 106 by forwarder module 144 and thedigital content not delivered by the forwarder module 144.Alternatively, if there is no delivery method or delivery destinationpresent the digital content may be delivered to the destinationidentifier using a delivery method corresponding to the destinationidentifier (e.g., if the destination identifier is an email address thedigital content may be sent in an email to the email address; if thedestination identifier is a telephone number the digital content may befaxed to the telephone number, etc.).

In still another embodiment, if there is no delivery method or deliverydestination present a notification may be sent to the destinationidentifier with a notification that content is available through theremote content access module 146 and a method of accessing remotecontent access module 146 (e.g., when the destination identifier is anemail address with no associated delivery method or deliverydestination, forwarder module 144 may send an email to the destinationidentifier including a URL link associated with the remote contentaccesses module 146 and an identifier for the digital content, etc.). Auser associated with the recipient may then access the remote contentaccess module 146 to retrieve such content.

If, however, there is a delivery method or delivery destinationassociated with the destination identifier present, in one embodiment,delivery of the digital content may comprise sending the digital contentto the delivery destination using the delivery method. This may entailsending the digital content to a URL, for example, associated with areceiving application, sending the digital content to a destinationtelephone number over the PSTN (e.g., using a fax server or faxservice), sending an encrypted email with the digital content to thedestination identifier if it is an email address, sending the content toa URL associated with the recipient's site, etc.

In one particular embodiment, the delivery method associated with adestination identifier may specify that the digital content is to beaccessed through remote content access module 146. In such embodiments,forwarder 144 may make the digital content 132 available for access byremote content access module 146.

Remote content access module 146 may provide an interface (e.g., a webpage or other interface accessible over network 110) through which usersmay access digital content 132 stored in data store 136. Thus, arecipient may access the remote content access module 146 and provide anidentifier associated with digital content. The recipient may benotified that content is available through the remote content accessmodule 146, for example, by an email including a URL link associatedwith the remote content accesses module 146 and an identifier for thedigital content. When the user clicks on such a link a browser at therecipient's site may access the remote content access module 146.

An interface may be presented by the remote content access module 146that allows the recipient to access and download the digital content 132associated with the identifier from the data store 136. In someembodiments, the user may be authenticated by the remote content accessmodule 146 before being allowed to access the digital content. Thisaccess may be accomplished used brokered authentication, for example,using a security token service (STS). Verification of a recipient'scredentials may also be verified using a 2-step verification process, bywhich credentials may be validated through a separate communicationchannel such as a mobile phone, etc.

While it should be understood from a review of the above descriptionthat embodiments as disclosed may be implemented using a wide variety ofarchitectures and hardware or software systems; that a content deliverysystem and the modules thereof may be one or multiple systems that mayor may not be distributed; that all of the modules presented herein mayor may not be one or multiple services (e.g., web services or the like)with one or more interfaces; and that these one or more services may beimplemented and accessed in a variety of manners, it will be useful hereto describe a particular embodiment in more detail.

For a variety of reasons, including reducing hardware, software andsupport requirements, it may be desirable to have a content deliverysystem remote from a user's site. However, embodiments of the systemsand methods disclosed herein may have many users and thus may entail theregistration of many destination identifiers, the implementation ofcomplex forwarders for particular delivery methods, the provisioning ofa large number of locations on the network or the ability to providemultiple simultaneous accesses, etc. Additionally, as users of such acontent delivery system may be geographically distributed it isdesirable to maximize user's access to the content delivery system toreduce downtime and allow substantially simultaneous access frommultiple users to the content delivery system.

Therefore, in one embodiment, an entity implementing embodiments of thesystems and method disclosed herein may implement modules associatedwith a content delivery system in a cloud based computing environment bydeploying services associated with a content delivery system using in acloud. By deploying the modules of the content delivery system in thecloud as services or other cloud based applications (collectivelyservices), such services can utilize the storage or other functionalityprovided by the cloud provider while achieving increased security,accessibility or reliability. In particular, deployment of such modulesin a cloud based computing environment may facilitate the reception,storage or delivery of content with respect to certain geographicregions which may be desirable based on customer location, customerdesire, regulations or for a wide variety of other reasons.

With that in mind, turning now to FIG. 2, one embodiment of anarchitecture of a content delivery architecture where servicesassociated with a content delivery system are deployed in a cloud basedcomputing environment is depicted. Content delivery architecture 200includes a network 270 over which the systems and modules communicate,including sending system 202, receiving systems 262, 264, and sendermodule 220, Managed File Transfer (MFT) forwarder module 242 and remotecontent access module 244 deployed in cloud 240 may communicate. Thecontent delivery system in such an architecture 200 may comprise thesending connector 204 deployed at the sending system 202 and modulesdeployed in the cloud 240.

Sending connector 204 is provided at a sending system 202 and may havean associated identifier (i.e., the sending connector identifier).Sending systems 202 may include computing devices having a processor forexecuting instruction such as, for example, personal computers, laptops,mobile computer devices, smartphones, personal data assistants, etc.Sending connector 204 at the sending system 202 may communicate with oneor more transmission initiators 206 who wish to send digital content.These transmission initiators 206 may be devices, application programsor other type client of the sending connector 204 associated withbusiness processes or individuals at the sending site, for exampleOutlook, a web service, an Oracle application, an SAP application,SharePoint, Lotus Notes, a fax server, etc.

In one embodiment, for example, a transmission initiator 206 may be aweb page on a browser executing on the sender system 202. In oneparticular embodiment, such a web page may be a web page that tracks aconversation between one or more senders or recipients of content, suchthat communications and digital content sent between the senders andrecipients may be tracked and presented over multiple communications

Accordingly, in certain embodiments the sending connector 204 may be alibrary (e.g., a .NET library or .c library or other type of library) orother type of plug-in or application that may be utilized in conjunctionwith these clients. In another embodiment, the sending connector 204 maybe part of a web page (e.g., an applet, plug-in, ActiveX program, etc.)that is executing on a browser, where the browser may be rendering a webpage that serves as transmission initiator 206. Such a web page may beprovided, for example, by sender module 220 (or another module)associated with the content delivery system. Thus, a web site or webpage may be provided by content delivery system such that when a browserat sending system 202 accesses the web page, a module (e.g., such as anapplet) may be executed by the browser in conjunction with accessing theweb page. This applet may be configured as sending connector 204 suchthat a user interacting with the web may provide digital content to thesending connector 204.

The sending connector 204 is configured to receive or otherwise obtaindigital content and an associated destination identifier from thetransmission initiator 206. The obtaining of digital content anddestination identifier may occur explicitly when a user or programprovides the digital content and destination identifier to the sendingconnector 204. For example, when a user interacts with an interface toindicate that he desires the digital content to be delivered using thecontent delivery system. The sending connector 204 may also obtain thedigital content and destination identifier without express userinvolvement such as when a client (e.g., Outlook or other email client)sends an email with digital content and the email is intercepted by thesending connector 204 or when the transmission initiator 206 is a webpage and the user utilizes the web page to send digital content.

The sending connector 204 is configured to send the destinationidentifier and digital content to the sender module 220 in the cloud andreturn a delivery status associated with the sending of the digitalcontent to the transmission initiator 206 which initiated thetransmission. Additionally, the sending connector 204 may be configuredto instruct a transmission initiator 206 or client associated withtransmission initiator 206 to perform actions in association with thesending of the content (e.g., to send an email or the like).

Receiving system 262 may have a browser 272 and one or more clientapplications 266 that may be used for notification or accessing digitalcontent, such as Outlook, SharePoint, Oracle, SAP, or another type ofapplication. Thus, it will be noted here that receiving of digitalcontent using embodiments of the content delivery system presentedherein may be accomplished without a receiving system 262 having anymodules or other applications specifically associated with the contentdelivery system (e.g., without having a sending connector 204 at thereceiving system).

Alternatively, a receiving system 264 may include a receiving module 268associated with the content delivery system. Such a receiving module 264may be configured to receive digital content from MFT forwarder module242 and provide the digital content to a client 274 at the receivingsystem, such as SharePoint (e.g., a SharePoint library or repository),Oracle, SAP, or another type of application. Such a receiver module 268may provide a location on the network (e.g., a URL or the like) and anassociated interface where digital content can be sent. This URL may bespecified, for example, as a delivery destination.

It will be noted here, that while receiver module 268 has, in thisembodiment, been depicted separately from sending connector 204, inother embodiments the functions of receiver module 268 and sendingconnector 204 may be incorporated into a single module. Similarly, itwill be noted that while sending systems and receiving systems have beendepicted separately, in many instances a sender of digital content mayalso desire to be a receiver of digital content. Accordingly, in someembodiments a sender system may be the same as, or used in associationwith, a receiver system and that such systems may have a sender andreceiver module (or a single module, or multiple distributed modules,that include the functionality of both the sender module and thereceiver module). Other configurations may also be possible and arefully contemplated herein.

Still referring to FIG. 2, cloud 240 is a cloud based computingplatform. A cloud may, for example, by a network of distributed serversor the like. In one embodiment, such a cloud based computing platformmay be, for example, Microsoft Windows Azure. Content delivery servicesassociated with the content delivery system that are deployed in thecloud 240 include sender 220, administration 276, managed file transfer(MFT) forwarder 242 and remote content access 244. These services mayhave one or more interfaces that may be accessed over network 270 using,for example, web pages, a web services interface based on hypertexttransfer protocol (HTTP), Simplified Object Access Protocol (SOAP), orother types of network protocols or interfaces.

The cloud 240 may provide certain services that may be utilized by thedeployed content delivery services, including for example the MicrosoftWindows Azure Storage services such as table storage, queue storage,blob storage, etc. This storage may be used during operation of thedeployed service and may store various configuration informationassociated with the services. Other services (not depicted) provided bythe cloud 240 may also be utilized (e.g., in the case of MicrosoftWindows Azure Platform: Web Role, Worker Role, VM Role, Access Control,Content Delivery Network, Caching, etc., other services in other cloudbased computing platforms may also be utilized).

Administration module 276 may allow an administrator associated withsending system 202 to generally manage accounts associated with sendingsystem 202 such as specifying one or more users, who they can senddigital content, what delivery methods a user may utilize, etc.Additionally, the administration module 276 is configured to provide aninterface by which a user (e.g., an individual user, an administrator,etc.) may register a destination identifier and provide destination dataassociated with the registered destination identifier or otherwisemanage an account related to the content delivery system. Thedestination data may include a delivery method or delivery destinationassociated with the destination identifier. For example, in associationwith a destination identifier the user may specify a delivery methodassociated with remote access delivery; may specify a delivery methodsuch as email and an associated delivery destination such as an emailaddress; may specify a delivery method of an application such asSharePoint or Oracle and a delivery destination such as a URL or othernetwork location associated with a module (e.g., receiver module 268)associated with that application; may specify fax over PSTN and anassociated telephone number as a delivery destination; may specify pointto point delivery (P2P) and provide a network location associated with adestination where such a location is associated with a fax server, etc.The administration module 276 may store the destination data inconfiguration table 222 in storage 246 provided by cloud 240.

Additionally, in some embodiments, as it may be desired to encrypttransmissions, the user may utilize administration module 276 to supplya public key that is part of a public/private key pair that may be usedas part of a public/private key encryption mechanism (such as, forexample, X.509 or the like).

When a transmission initiator desires to send digital content thedigital content and an associated destination identifier is received atsending connector 204. As has been noted above, in some embodiments thesending connector 204 may be a plug-in or other module that operateswith a transmission initiator 206 such that the digital content may beintercepted unobtrusively with respect to the operation of thetransmission initiator 206 while in other embodiments the sendingconnector 204 may be executing as part of a web page being accessed by auser at sending system 202. The sender connector 204 may send thedestination identifier to the sender module 220, for example, as part ofa request to send digital content to the destination identifier.

Sender module 220 is configured to verify the received destinationidentifier by determining if the destination identifier is inconfiguration table 222. If the destination identifier is not in theconfiguration table 222 the sender module 220 may return an error to thesender connector 204. If the destination identifier is in theconfiguration table 222 the sender module 220 may return a token orother transmission permission or identifier (collectively referred toherein as a transmission identifier) such as a GUID to the senderconnector 204.

In one embodiment, the sender module 220 may also be configured to checkentitlements, including for example, permissions or account informationassociated with the sending system 202 or an associated deliverydestination. If the entitlements indicate that the sending system 202,user, etc. does not have permission to send digital content the sendermodule may return an error to the sender connector 204 where the errormay include a notification of why the request could not be completed.

If an error or other indication of denial is returned to the sendingconnector 204 the sending connector 204 may indicate an error or offeralternative options to the transmission initiator 206. If a token orother transmission permission or identifier is received at the sendingconnector 204 the sending connector 204 may transmit the digital contentand associated metadata to sender module 220. The metadata may comprise,for example, an XML file indicating the size, type, author, date, orother data associated with the digital content.

In one embodiment, the sending connector 204 may transmit the digitalcontent in one or more chunks to the sender module 220. The size ofthese chunks may be configurable or may be determined based on a widevariety of criteria (e.g., protocol, bandwidth availability, size ofdigital content, etc.) and may be static or may change dynamicallyduring the transmission. For example, the digital content may beseparated into chunks of 16 kb, 32 kb, 64 kb or 128 kb for transmission.Additionally, if encryption is being utilized the chunks may beencrypted using, for example, a public/private key pair associated witha public key received from sender module 220. A checksum can also becalculated by the sending connector 204 for each chunk beingtransmitted.

After the transmission of each chunk, the sending connector 204 mayverify the status of the transmission of that chunk. In one embodiment,when a transmitted chunk is received by sender module 220, the sendermodule 220 may calculate the checksum for the received chunk and returnthe checksum to the sending connector 204. The sending connector 204 maycompare the received checksum to the checksum calculated for the chunkbefore the chunk was transmitted to verify the transmission of thatchunk. If the transmission of a chunk cannot be verified, an action maybe taken. This action may include reporting the error to thetransmission initiator 206.

Additionally, after the last chunk of the digital content has been sentto the location, the delivery of the digital content may be verified aswell. This verification may be accomplished by sender connector 204querying sender module 220 at regular intervals for the status andproviding a token or other transmission permission or identifier (e.g.,as received from the sender module 220) associated with the digitalcontent. The sender module 220 may obtain the status of the job fromdelivery status queue 284 using the provided token or other transmissionpermission or identifier and return the status in response to thisrequest. If the delivery cannot be verified an action may be taken. Thisaction may include reporting the error to the transmission initiator206.

Sender module 220 is thus configured to receive the chunks of thedigital content associated with the destination identifier transmittedfrom the sending connector 204 and metadata associated with the digitalcontent. The sender module 220 stores the received chunks in chunkstorage 224 in association with the transmission identifier, stores themetadata in association with the transmission identifier and may createan entry in the delivery status queue 284 associated with thetransmission identifier along with an initial status. To ensuresecurity, it may be the case that all digital content stored in chunkstorage 224 may have a time to live (or expiration date) such that theyare deleted after a certain period of time (e.g., 30 days, 60 days, 90days, etc.) even if the delivery of such content is never confirmed ornever actually takes place. Moreover, chunk storage 224 may, in someembodiments, be distributed across geographic regions such that receivedchunks may be stored in a desired geographic region based on a widevariety of criteria, such as customer location, customer desire, rulesand regulations, etc.

Additionally, sender module 220 accesses configuration table 222 todetermine destination data associated with the received destinationidentifier, including for example the delivery method or deliverydestination associated with the destination identifier. The sendermodule 220 is configured to place a transmission job in monitor queue226. This transmission job may comprise the transmission identifier(e.g., sent to sending connector 204) which is also associated withchunks of digital content in chunk storage 224 and allows identificationof those chunks. Additionally, the transmission identifier may allowidentification of the metadata associated with the digital content whichmay be stored in storage 246. Data associated with the delivery methodor the delivery destination or which allows determination of thedelivery method or the delivery destination may also be stored inassociation with the transmission job in monitor queue 226.

Monitor module 232 is configured to check monitor queue 226 (or benotified when a transmission job is pending or placed in monitor queue226) and obtain a transmission job from monitor queue 226. Based on themetadata, the delivery method, the delivery destination or other dataassociated with the transmission job, the monitor module 232 may sendthe transmission job to a queue associated with an appropriateforwarder. Almost any queuing algorithm desired may be utilized todetermine the priority of transmission jobs in monitor queue 226.

In one embodiment, if the metadata, the delivery method, or the deliverydestination associated with the obtained transmission job indicate thatthe digital content associated with that transmission job is to bedelivered using the remote content access module 244, the transmissionjob may be placed in remote content access queue 225 while if themetadata, the delivery method or delivery destination indicate that thedigital content is to be sent to a delivery destination the transmissionjob may be placed in MFT forwarder queue 228.

Each of the MFT forwarder 242 and remote content access forwarder 236are configured to check their respective associated queues (MFTforwarder queue 228 and remote content access queue 225), or be notifiedwhen a transmission job is pending in their respective queue, obtain thetransmission job from their respective queue.

When MFT forwarder 242 obtains a transmission job from MFT forwarderqueue 228 it may access the chunks of digital content associated withthe transmission job (e.g., using the transmission identifier associatewith the transmission job) in chunk storage 224, assemble the digitalcontent from the obtained chunks and store the digital content in thecontent storage 282 in association with the transmission identifier.Similarly to chunk storage 224, content storage 282 may, in someembodiments, be distributed across geographic regions such that receivedchunks may be stored in a desired geographic region based on a widevariety of criteria, such as customer location, customer desire, rulesand regulations, etc.

MFT forwarder 242 may then send the assembled digital content to thereceiver module 268 associated with the delivery method or thedestination identifier. Alternatively, the delivery method associatedwith the obtained transmission job may indicate that only metadata onthe digital content is desired. In such cases the MFT forwarder 242 mayobtain metadata associated with the digital content associated with thetransmission job and deliver such metadata to the receiver module 268associated with the delivery method or the destination identifier.

After delivering the digital content (or metadata), MFT forwarder module242 may place a delivery status confirmation on the delivery statusqueue 284 in association with the transmission job and delete thedigital content from storage 246 (this deletion may entail the deletionof the digital content associated with the transmission identifier fromcontent storage 282 or the deletion of digital content from anywhere instorage 246, such as chunks of the digital storage from chunk storage224). To ensure security, it may be the case that all digital contentstored in content storage 282 (or storage 246 generally) may have a timeto live (or expiration date) such that they are deleted after a certainperiod of time (e.g., 30 days, 60 days, 90 days, etc.) even if thedelivery of such digital content is never confirmed or never actuallytakes place.

Receiver module 268 at receiving system 264 thus receives the digitalcontent from MFT forwarder 242 and may then provide this receiveddigital content (or received metadata) to client 274 at the receivingsystem 264.

Similarly, when remote content access forwarder 236 obtains atransmission job from remote content access queue 225 it may access thechunks of digital content associated with the transmission identifier ofthe transmission job in chunk storage 224, assemble the digital contentfrom the obtained chunks and store the digital content in contentstorage 282 in association with the transmission identifier. The area ofcontent storage 282 where the digital content is stored by remotecontent access forwarder 236 may be accessible through, or utilized by,remote content access module 244. Additionally, remote content accessforwarder 236 may assign permissions to that digital content based onthe destination identifier associated with the transmission job suchthat the digital content is accessible (or only accessible) throughremote content access module 244 to a user with the correct credentials.

After storing the digital content in the content storage 282 andassigning permissions, the remote content access forwarder 236 may placea delivery status confirmation on the delivery status queue 284 inassociation with the transmission job. Again, to ensure security, it maybe the case that all digital content stored in content storage 282 (orstorage 246 generally) may have a time to live (or expiration date) suchthat they are deleted after a certain period of time (e.g., 30 days, 60days, 90 days, etc.) even if such content is never accessed using remotecontent access module 244 as described below.

Remote content access module 244 may provide a website or otherinterface through which documents can be viewed, downloaded or otherwiseaccessed. Thus, a user may access the remote content access module 244through, for example, a browser 272 at receiving system 262 and identifydigital content which it is desired to access. Using the permissionsassociated with the identified digital content, the remote contentaccess module 244 may authenticate the user. This authentication may bedone using, for example, a Security Token Service (STS). If the user isauthenticated they may be allowed to access the digital content in thecontent storage 282. In one embodiment, remote content access module 244may be similar to SecureDocs by OpenText Corporation and may be awebsite using ASP.Net and the model view control (MVC) framework.

As digital content is not delivered directly to a user at receivingsystem 262 such users or other recipients (e.g., applications) may notnecessarily be aware when such content is available, nor may they have amethod to identify such digital content to remote content access module244. Thus, in some embodiments, a notification associated with suchdigital content may be provided to a recipient at the receiving system262. This notification may be delivered through a client 266. Thisclient 266 may be the same type of client as was used to initiate thetransmission of the digital content at the sender system 202 (e.g., asending connector) and may provide a way to identify the digital contentto the remote content access module 244. Thus, in certain embodiments anotification may be provided using the delivery method intended by thesender while the digital content itself may be delivered using thatdelivery method or another delivery method altogether.

For example, in cases where the destination identifier denotes a URL apush notification with an identifier for the content may be sent to theURL to identify that content is available. This digital content may beobtained, for example, by the client 266, using an API and the providedidentifier and the digital content received in response to this requestprovided to a recipient (e.g., an application using client 266 as aplug-in, etc.).

In another embodiment, in cases where the destination identifierassociated with a transmission job is an email address an email may besent to the destination identifier associated with the transmission job,where the email includes a link with a URL that includes the websiteprovided by the remote content access module 244 and identifies thedigital content associated with the transmission job. Thus, when a userof receiving system 262 receives such an email he may click on the linkincluded in the email. The HTTP request with the URL may then be sent tothe remote content access module 244 where the URL identifies thedigital content. The website provided by the remote content accessmodule 244 may then be brought up in the browser 272 at the receivingsystem 262 and the user allowed to access the digital content. Such anemail may be sent, by example by the sending connector 204 (e.g., usingthe transmission initiator 206 in the case where the transmissioninitiator 206 is an email client such as Outlook) or may be sent by theremote content access module 244 itself.

More specifically, in one embodiment, if the transmission initiator 206is an email client, the user may compose an email with digital contentand a destination identifier (e.g., an email address). The sendingconnector 204 may receive this email (e.g., because the user indicatedthat he wishes to send the digital content using the content deliverysystem or because all emails having attachments are routed through thesending connector 204, etc.). The sender connector 204 may transmit thedestination identifier to the sender module 220, for example, as part ofa request to send digital content to the destination identifier.

When a transmission identifier is received from the sender module 220 inresponse to a request to send digital content, the transmissioninitiator 206 may modify the originally received email to create anotification email by removing the digital content and inserting amessage with a URL associated with the remote content access module 244and including the transmission identifier received from the sendermodule 220. The notification email can then be sent to the destinationidentifier provided by the user. The delivery of the content using thecontent delivery system may progress substantially as described above.

When the receiving user receives the notification email, this user maythen bring up the website provided by the remote content access module244 at the receiving system 262 by clicking the link in the notificationemail and the user will be allowed to access the digital contentassociated with the transmission identifier in content storage 282 asdescribed.

Thus, a content delivery system may be utilized to deliver digitalcontent using an appropriate delivery method or to an appropriatedelivery destination without respect either to the format of suchdigital content or the method by which the content was originally sentor the method of delivery intended by the sender of such content.

FIGS. 3A-3E depict one embodiment of a method employed by embodiments ofa content delivery system to send or deliver digital content. At step310 digital content may be received. This digital content may bereceived along with an associated destination identifier indicatingwhere the sender desires the digital to be sent. For example, thisdigital content may be received from a plug-in associated with a SAP,Oracle, SharePoint, Office 365, Lotus Notes, etc. application andassociated with a network location or URL. In one embodiment, a plug-inmay be utilized to intercept digital content at a certain point in awork flow involving such an application, where that point in theworkflow is associated with a particular destination identifier.

Alternatively, a user may use an email client such as Outlook to createan email with an attachment where the email specifies an address (e.g.,an email address, SMTP address, etc.) as the destination identifier. Aplug-in may provide an interface by which the user may choose to sendthe email an in a secure manner or the email may be intercepted by theplug-in without any action from the user. A user may also desire to senddigital content as a fax, in such cases, the digital content may beprovided to a fax server (e.g., such as RightFax by OpenTextCorporation) along with a destination identifier of a phone number.Another method by which content may be received is through a web site.Such a web site may be configured to allow a user to select content tobe sent using the content delivery system and provide a destinationidentifier to which the content is to be sent.

At step 320 then, the digital content and the destination identifierspecified by the sender (e.g., by the application or the user who sentthe content) may be sent to a centralized portion of the contentdelivery system. For example, this portion of the content deliverysystem may be distributed among many computing devices or reside in acloud based computing system, etc. When the digital content andassociated destination identifier is received, it can be determined atsteps 330 and 340 if the destination identifier is registered.

In one embodiment, a user have registered such a destination identifierand provided destination data associated with the registered destinationidentifier. The destination data may include a delivery method ordelivery destination associated with the destination identifier. Forexample, in association with a destination identifier a user such as acustomer or administrator may specify a delivery method associated withremote access delivery; may specify a delivery method such as email andan associated delivery destination such as an email address; may specifya delivery method of an application such as SharePoint or Oracle and adelivery destination such as a URL or other network location associatedwith a module associated with that application; may specify fax overPSTN and an associated telephone number as a delivery destination; mayspecify point to point delivery (P2P) and provide a network locationassociated with a destination where such a location is associated with afax server, etc. Accordingly, at steps 330 and 340 it can be determinedif the received destination identifier has been previously registeredand, if so, the corresponding delivery method or delivery destinationassociated with the registered destination identifier.

In certain embodiments, it can also be determined at steps 330 and 340,if the sender or recipient associated with the received destinationidentifier has a valid entitlement to send or receive data respectively.

If the destination identifier is not registered (or does not have avalid entitlement) the sender may be given an error message at step 350.Additionally, the sender may be presented with the option of sending thedigital content via an email message.

Alternatively, at step 352, if the destination identifier is notregistered the digital content may be sent to the destination identifierusing a delivery method corresponding to the destination identifier(e.g., if the destination identifier is an email address the digitalcontent may be sent in an email to the email address; if the destinationidentifier is a telephone number the digital content may be faxed to thetelephone number, etc.). In another embodiment, if there is no deliverymethod or delivery destination registered a notification may be sent tothe destination identifier (e.g., using a method corresponding with thedestination identifier) with a notification that content is available amethod of accessing the digital content.

Now referring to FIG. 3B, if the destination identifier is registered itcan be determined if fax was the sender's intended delivery method atstep 360. This can be determined, for example, by the plug-in from whichthe digital content was received, an indication of the user with respectto the sending interface, the type of the destination identifier (e.g.,telephone number), etc. If fax is the sender's intended method ofsending the digital content, a fax server associated with the sender maybe determined at step 370 (e.g., using the sender's identity). This faxserver may be a fax server local to the sender or may be a hosted faxserver. The digital content can then be sent to the fax serverassociated with the sender which converts the digital content to TIFF.The digital content in TIFF format can then be obtained at step 380 fordelivery to the destination identifier. Examples of fax servers or faxsystems that may be utilized according to embodiments depicted hereinare U.S. patent application Ser. No. 13/485,140, entitled “System andMethod for Sending, Delivery and Receiving of Faxes,” filed May 31, 2012and U.S. patent application Ser. No. 13/461,351, entitled “System andMethod for Sending, Delivery and Receiving of Faxes,” filed May 1, 2012,hereby incorporated by reference herein in their entirety.

At step 390, if fax is not the sender's intended delivery method, thedelivery method associated with the destination identifier can bedetermined. The delivery method may have been specified by a recipientin conjunction with the recipients provided destination identifiers, asdiscussed above. Thus, the delivery method associated with thedestination identifier specified by the sender in association with thedigital content may be determined. The digital content may be providedto a forwarder associated with the determined delivery method at step322. This forwarder may be provided in a cloud and be multi-tenanted,could be dedicated to a particular recipient and reside in the cloud, ormay be dedicated to a particular recipient and located at a siteassociated with the recipient.

Moving to FIG. 3C, when the forwarder receives the digital content, theforwarder may determine the delivery method associated with the digitalcontent at step 332. In one embodiment, the delivery method may beprovided to the forwarder along with the digital content, in anotherembodiment the forwarder may determine the recipient's specifieddelivery method substantially as described above.

It can then be determined at step 342 if the recipient's specifieddelivery method associated with the destination identifier is fax. Ifthe recipient's specified delivery method is fax (and, in oneembodiment, if the digital content has not previously been converted toTIFF or was not already in TIFF) the digital content may be converted tothe TIFF. This conversion may be accomplished, in one embodiment, bydetermining a fax server associated with the receiver at step 352 (e.g.,which may have been specified in conjunction with the destinationidentifier). This fax server may be a fax server local to the receiveror may be a hosted fax server. The digital content can then be sent to afax server associated with recipient which converts it the digitalcontent to TIFF and may send the digital content at step 353 using a faxsystem over a network such as that discussed in U.S. patent applicationSer. No. 13/485,140, entitled “System and Method for Sending, Deliveryand Receiving of Faxes,” filed May 31, 2012 and U.S. patent applicationSer. No. 13/461,351, entitled “System and Method for Sending, Deliveryand Receiving of Faxes,” filed May 1, 2012, hereby incorporated hereinby reference in their entirety. Alternatively, the digital content maybe sent to the destination identifier over the PSTN at step 355 using,for example, a cloud based system for sending faxes over the PSTN.

Referring now to FIG. 3D, delivery of the digital content to therecipient may then be initiated at step 372 based on the recipient'sspecified delivery method. At step 382 it can be determined if therecipient's specified delivery method involves notification to therecipient and a notification destination (which may be the same as, ordifferent than, the delivery destination) associated with the deliverymethod may be determined.

If notification is involved, the forwarder may send a notification tothe notification destination at step 392 and a recipient may receivesuch a notification at step 324. For example, in certain embodiments anemail may be sent to provide notification to the recipient that digitalcontent is available. For example, in cases where the destinationidentifier denotes a URL a push notification with an identifier for thecontent may be sent to the URL to identify that content is available.

If the recipient's specified delivery method requires that the recipientpull the or otherwise manually access the content at step 334 (e.g.,using a website or an API, as discussed above) the recipient may accessthe content at step 344. In one embodiment, the user may log onto oraccess the web site or other application and download the digitalcontent. This access may be facilitated by the user through the formatof the notification. For example, as discussed above the notification(e.g., email) itself may be used to access the website or applicationthrough which the content may be provided. In another embodiment, thedigital content may be accessed, for example, by the recipient using anAPI and an identifier for the digital content provided in anotification. This embodiment may be useful in instances when therecipient is an application as the application may be configured toaccess such digital content using the API substantially without userinvolvement. Accordingly, any workflows or processing dependent on thereceipt of such content may not be suspended or otherwise idled longerthan necessary when waiting for such digital content.

Returning to step 382, if the recipient's specified delivery method doesnot involve a notification the content may be sent to a recipient at aspecified delivery destination at step 354 using an appropriate deliverymethod (e.g., sending the digital content via HTTP to a network locationspecified by the recipient as the delivery destination in associationwith the destination identifier provided by the sender, sending an email(that may be encrypted) to an email address specified as the deliverydestination, sending a fax to a telephone number specified as thedelivery destination, etc.). The digital content may then be integrateddirectly into the recipient's system (e.g., an SAP application, aSharePoint library, etc.) where appropriate or otherwise utilized asdesired.

Moving on to FIG. 3E, once the digital content is delivered then, anotification of delivery of this digital content may be sent to theoriginal sender at step 364. The sender may receive such a notificationat step 374 and the content deleted from the content delivery system atstep 384. To ensure security, it may be the case that digital content onthe content delivery system may be deleted after a certain period oftime (e.g., 30 days, 60 days, 90 days, etc.) even if the delivery oraccess of such content is never confirmed or never actually takes place.Additionally, in certain embodiments, the original sender of suchdigital content may also delete content. It will be noted that whilethis step is depicted after the digital content is sent to therecipient, in certain embodiments the digital content may be deletedbefore the sending of such digital content (e.g., if the sender nolonger desires to send such digital content, etc.).

It may now be helpful here to discuss other embodiments of systems forcontent delivery. Accordingly, FIG. 4 depicts one embodiment of anarchitecture of a transactional system 400 that may be used for contentdelivery where services associated with content delivery are deployed ina cloud-based computing environment 470. Here, transactional system 400includes a transaction engine 410 for sending and receiving content(generally denoted by reference numeral 401) and executing on a server.Transaction engine 410 includes sender 440 for receiving content 401from a sender (generally denoted by reference numeral 404 a) using asender device (as may the same or similar to devices 104 a, 104 b, 104 cdescribed in conjunction with FIG. 1) and sender configurationinformation 441. Transaction engine 410 further includes a forwarder 442for sending the content 401 to a recipient (generally denoted byreference numeral 404 b) on a recipient device (as may be the same orsimilar to devices 104 d, 104 e, 104 f described in conjunction withFIG. 1), recipient configuration information 443, and a storage device436 coupled to the transaction engine 410 for storing the content 401.

In a further embodiment, sender configuration information 441 includesinformation related to a delivery method 441 a for delivery of thecontent 401 to the transaction engine 410 via the sender device,delivery parameters 441 b to control content delivery, and a destinationidentifier 441 c denoting a receipt address for a recipient 404 b. Thesender configuration information can be defined by the sender 404 a andreceived via the sender device. In such embodiments, the sender 404 acan use a sender connector 406 a resident on the sender device to definethe sender configuration information 441. The sender connector 406 a canbe a plug-in to an application, such as an email program or a standalonemodule in communication with an application (an example of which isdenoted on FIG. 4 as APPL'N1).

In some embodiments, delivery method 441 a can include an emailprotocol, hypertext transfer protocol, and/or a delivery method of aparticular application such as those describes herein above withreference to FIG. 1. Destination identifier 441 d can include an emailaddress, a uniform resource locator (URL), and other destinationidentifiers described herein above in conjunction with FIG. 1. Deliveryparameters 441 b include a variety of parameters useful to effectivelyand purposefully control the delivery of content 401, such as encryptioninformation, content type and size information, information for packetsand sub-packets including pieces of the content 401, content format,sender credentials, certain application and/or contextual requirementsfor content transactions, such as content classifications, accesspermissions, expiry information, regional information, etc.

In another embodiment, recipient configuration information 443 includesinformation related to a receiver method 443 a for delivery of thecontent 401 from the transaction engine 410 to a recipient device, andreceiver parameters 443 b to further control content delivery. In suchembodiments, the recipient 404 b can use a receiver module 406 cresident on the recipient device to define the recipient configurationinformation 443. Much like the sender connector 406 a, 406 b, thereceiver module 406 c can be a plug-in to an application or a standalonemodule in communication with an application (an example of which isdenoted on FIG. 4 as APPL'N2).

In some embodiments, receiver method 443 a can include a method ofcontent delivery expected by an application 405 c. As such, the receivermethod 443 a can include an email protocol for an email program,hypertext transfer protocol for an Internet browser, and/or a receivermethod of a particular vendor application such as those described hereinabove with reference to FIG. 1. Receiver parameters 443 b can include avariety of parameters useful to effectively and purposefully control howa recipient receives (and/or expects to receive) content 401, many ofwhich can mirror the delivery parameters 441 b. Receiver parameters 443b can include content type, regional storage information, validationinformation to validate the content, integration information forintegrating and packaging the content for the recipient, and securityinformation.

In some embodiments, transactional system 400 is deployed in acloud-based computing environment 470 including a plurality ofdistributed network servers. Here, the servers can be under the controlof a service entity enabling use of the transactional system 400 byapplications, other systems, and/or users. The service entity canconfigure content transaction information (such as sender configurationinformation 441 and/or recipient configuration information 443) andsetup and maintain servers as needed to handle one or more clients. Assuch, transactional system 400 (its users and clients) can realize thebenefits of cloud-based computing environments.

In further embodiments, storage device 436 includes at least one storagedevice located in a predetermined geographic region. For example, one ormore storage devices 436 c can be located in the United States and/orone or more other storage devices 436 d can be located in Europe. Thisenables content storage requirements to follow certain requirements andguidelines, such as those promulgated by the United States Department ofHomeland Security (DHS). The DHS may require, for example, that certaincontent 401 of a particularly sensitive nature be stored in apreordained location, such as a secure server within the boundaries ofthe United States. As such, the predetermined geographic region can beconfigured by sender 404 a, a transaction engine administrator, and/or arecipient 404 b as needed or desired.

Further to the above, the predetermined location may be based on thedata sovereignty requirements of a particular country or region, such asthe European Union. In such instances, content for European users may bestored on storage devices located in Europe. In other instancesinvolving clients in the United States, content may be stored in theUnited States where it is accessible according to the laws of the UnitedStates, such as the Patriot Act.

In other embodiments, sender configuration information 441 furtherincludes a transmission identifier 441 c, which can be a uniqueidentifier associated with the content 401. In still further embodiment,the content 401 is stored as a plurality of storage pieces (generallydenoted by reference numeral 437) on the storage device 436 b. Thestorage pieces 437 are associated with the transmission identifier 441 c(referred to as T_ID in FIG. 4). This can enable the transaction engine410 to identify separate pieces of content 401 with a singletransmission to forward to recipients.

In some embodiments, transaction engine 410 further includes anotification module 490 for configuring notifications to at least one ofthe sender 404 a and the recipient 404 b. Such notifications can includethose described with reference to FIGS. 3A-3E.

It should be noted that in some embodiments of the transactional system400, the transaction engine 410 sends/receives content 401 from sender404 a to recipient 404 b either of whom at least partially defines theconfiguration information. However, the transaction engine 410 can alsobe configured to enable content transactions between differentapplications, such as an email program and a content server without anyuser intervention. In such instances, the applications may bepreconfigured with respective sender configuration information 441 andrecipient configuration information 443 to automatically enable contenttransactions. Advantageously, the transaction engine 410 can beconfigured to handle content using methods and formats appropriate forsuch applications. For example, the transaction engine 410 can beconfigured to receive content 401 in a manner a particular applicationexpects to send content 401 and send the content 401 in a manner anotherparticular application expects to receive the content 401. This canenhance and facilitate content transactions across differentapplications and systems (with different users and/or user groups) andcan also reduce complexity, setup time and maintenance and increaseflexibility and transparency.

In a further embodiment, the transaction engine 410 is configured todelete the content 401 on the storage device 436 based on the elapse ofa predetermined amount of time the content 401 is stored on the storagedevice 436. Such expiry information 450, much like the predeterminedgeographic region described herein above, can be based on securityrequirements of the content 401. For example, security requirements candictate that content 401 not be stored on storage device 436 for morethan a predetermined amount of time. Such a requirement may reducesecurity risks associated with content 401 by limiting the amount oftime content 401 is stored on security device 436 where it may becompromised by hackers or thieves.

Referring now to FIG. 5, in a further embodiment, a content deliverysystem 500 (which may include components of the transactional system 400described in conjunction with FIG. 4) includes a content delivery engine510 for sending and receiving content 501 and executing on a server. Thecontent delivery engine 510 includes a sender connector 540 forreceiving content 501 from a sender device (generally denoted byreference numeral 504 a) and sender configuration information includinga delivery method 541 a for delivery of the content 501 to the contentdelivery engine 510. The sender configuration information can alsoinclude a destination identifier 542 b denoting a receipt address for arecipient.

The content delivery engine 510 further includes a forwarder 542 forsending the content 501 to the recipient, recipient configurationinformation including a receiver method 543 a for delivery of thecontent 501 from the content delivery engine 510 to a recipient device(generally denoted by reference numeral 504 b), and a storage device 536coupled to the content delivery engine 510 for storing the content 501.

The delivery method 543 a can include a method of delivery accepted orexpected by an application 575 and/or desired by a user on the recipientdevice 504 b. For example, the delivery method 543 a can include methodsutilized by a content integration systems such as those manufactured bySAP Corporation or Microsoft Corporation such as Microsoft Sharepoint.The delivery method 543 b may include configuration information such ascontent type, regional storage information, and/or encryptioninformation for encrypting/decrypting the content 501 for securedelivery.

The content delivery engine 510 maps the receipt address 541 b to areceiver method 543 a based on the needs and requirements of a userand/or application 575 executing on the recipient device 504 b. Forexample, the application 575 may include a workflow application and thereceiver method 543 a may include information for updating, modifying,and/or packaging the content 501′ for automatic ingestion into theworkflow application. The forwarder 542 sends the content 501′ to therecipient device 504 b according to the mapped receiver method. In someembodiments, the receiver method 543 a includes a plurality of receivermethods, at least a portion of which are predefined according to a suiteof applications. The receipt addresses for a group of applications maybe pre-mapped to receiver methods (and stored in a table) to enableautomatic ingestion of the content 501′ into a particular application.

In some embodiments, an administrator defines, updates, and maintainsreceipt address-receiver method mappings and such mappings can be storedin a variety of formats. For example, the mappings can be arranged in adatabase table accessible to the administrator. In the same or differentembodiment, senders, recipients, or a combination thereof can define atleast a portion of the mappings.

In further embodiments of the content delivery system 500, the deliverymethods are mapped to a sender address to enable the content deliveryengine 510 to receive content 501 in a manner utilized by the senderdevice 504 a. The delivery methods may be predefined according to asuite of applications so that the content deliver system 500 can acceptcontent 501 in the appropriate format without any need to specifycertain content information for each delivery.

It may be useful to an understanding of certain embodiments to viewembodiments of interfaces that may be utilized with embodiments of acontent delivery system or a transactional system as disclosed herein.Turning first to FIG. 6, an embodiment of an interface that may bepresented by a sending connector integrated in an email application isdepicted. Here, while sending an email, to send an email a sending usemay configure a sending connector for a content delivery system suchthat the portion 410 of the interface presented is associated with asending connector for sending the digital content of the email (e.g.,the attachment to the email) using a content delivery system associatedwith the sending connector. Additionally, here, the interface 410 allowsthe user to configure the sending connector according to the user'spreferences.

FIG. 7 depicts an embodiment of an interface that includes a sendingconnector for a content delivery system. Specifically, here, interface590 may be a web page rendered by a browser where the web page presentsan interface that allow a one or more destination identifiers to bespecified and digital content to be selected (e.g., from a system onwhich the web page is being rendered). Such a web page may include asending connector such that the destination identifier and digitalcontent specified through the interface 590 may be received by thesending connector.

FIG. 8 depicts an embodiment of another interface that includes asending connector for a content delivery system. In this embodiment,interface 610 may be a web page rendered by a browser where the web pagepresents an interface that allow a conversation between one or moreusers to be depicted. Such a conversation may be associated withdestination identifiers for each participant such that each participantin the conversation may use such an interface to select digital (e.g.,from a participant's system on which the web page is being rendered) andassociated with the destination identifiers of participants in theconversation. Such a web page may include a sending connector such thatthe destination identifier and digital content specified through theinterface 610 may be received by the sending connector.

Moving to FIG. 9, an embodiment of an interface for a notification thatmay be sent by a content delivery system to a recipient is depicted.Here, interface 710 is an email that has been sent to the recipient thatincludes a link 720 identifying digital content by which the recipientmay access the digital content. Specifically, interface 710 is an emailthat may be received by a participant in the conversation depicted inthe interface of FIG. 8. When such a participant clicks on the link theweb page associated with that conversation may be accessed by a browserat the recipient's system. The recipient may be authenticated by thatweb page and allowed to download the digital content. Thus, notificationwas provided interface 710 but digital content was accessed through theweb page referenced in the notification.

Referring now to FIG. 10, an embodiment of an interface for anotification that may be sent by a content delivery system to a senderof digital content when such content is delivered is depicted. Here,interface 810 is an email that has been sent to the sender of contentthat identifies the recipient and the digital content which has beendelivered to that recipient. Specifically, interface 810 is an emailthat may be received by a participant in the conversation depicted inthe interface of FIG. 8 who sent content to another participant. Whenthe participant who was the recipient accessed the sent content thecontent delivery system sent an email to the sending participant thatnotifies the sending participant that the digital content was accessed,the recipient participant who accessed the content and, in this example,the conversation. Thus, delivery notification was provided through emailinterface 810 but digital content was sent and through a web pageprovided by the content delivery system.

Although the invention has been described with respect to specificembodiments thereof, these embodiments are merely illustrative, and notrestrictive of the invention. The description herein of illustratedembodiments of the invention is not intended to be exhaustive or tolimit the invention to the precise forms disclosed herein (and inparticular, the inclusion of any particular embodiment, feature orfunction is not intended to limit the scope of the invention to suchembodiment, feature or function). Rather, the description is intended todescribe illustrative embodiments, features and functions in order toprovide a person of ordinary skill in the art context to understand theinvention without limiting the invention to any particularly describedembodiment, feature or function.

While specific embodiments of, and examples for, the invention aredescribed herein for illustrative purposes only, various equivalentmodifications are possible within the spirit and scope of the invention,as those skilled in the relevant art will recognize and appreciate. Asindicated, these modifications may be made to the invention in light ofthe foregoing description of illustrated embodiments of the inventionand are to be included within the spirit and scope of the invention.Thus, while the invention has been described herein with reference toparticular embodiments thereof, a latitude of modification, variouschanges and substitutions are intended in the foregoing disclosures, andit will be appreciated that in some instances some features ofembodiments of the invention will be employed without a correspondinguse of other features without departing from the scope and spirit of theinvention as set forth. Therefore, many modifications may be made toadapt a particular situation or material to the essential scope andspirit of the invention.

Reference throughout this specification to “one embodiment,” “anembodiment,” or “a specific embodiment” or similar terminology meansthat a particular feature, structure, or characteristic described inconnection with the embodiment is included in at least one embodimentand may not necessarily be present in all embodiments. Thus, respectiveappearances of the phrases “in one embodiment,” “in an embodiment,” or“in a specific embodiment” or similar terminology in various placesthroughout this specification are not necessarily referring to the sameembodiment. Furthermore, the particular features, structures, orcharacteristics of any particular embodiment may be combined in anysuitable manner with one or more other embodiments. It is to beunderstood that other variations and modifications of the embodimentsdescribed and illustrated herein are possible in light of the teachingsherein and are to be considered as part of the spirit and scope of theinvention.

In the description herein, numerous specific details are provided, suchas examples of components and/or methods, to provide a thoroughunderstanding of embodiments of the invention. One skilled in therelevant art will recognize, however, that an embodiment may be able tobe practiced without one or more of the specific details, or with otherapparatus, systems, assemblies, methods, components, materials, parts,and/or the like. In other instances, well-known structures, components,systems, materials, or operations are not specifically shown ordescribed in detail to avoid obscuring aspects of embodiments of theinvention. While the invention may be illustrated by using a particularembodiment, this is not and does not limit the invention to anyparticular embodiment and a person of ordinary skill in the art willrecognize that additional embodiments are readily understandable and area part of this invention.

Any suitable programming language can be used to implement the routines,methods or programs of embodiments of the invention described herein,including C, C++, Java, assembly language, etc. Different programmingtechniques can be employed such as procedural or object oriented. Anyparticular routine can execute on a single computer processing device ormultiple computer processing devices, a single computer processor ormultiple computer processors. Data may be stored in a single storagemedium or distributed through multiple storage mediums, and may residein a single database or multiple databases (or other data storagetechniques). Although the steps, operations, or computations may bepresented in a specific order, this order may be changed in differentembodiments. In some embodiments, to the extent multiple steps are shownas sequential in this specification, some combination of such steps inalternative embodiments may be performed at the same time. The sequenceof operations described herein can be interrupted, suspended, orotherwise controlled by another process, such as an operating system,kernel, etc. The routines can operate in an operating system environmentor as stand-alone routines. Functions, routines, methods, steps andoperations described herein can be performed in hardware, software,firmware or any combination thereof.

Embodiments described herein can be implemented in the form of controllogic in software or hardware or a combination of both. The controllogic may be stored in an information storage medium, such as acomputer-readable medium, as a plurality of instructions adapted todirect an information processing device to perform a set of stepsdisclosed in the various embodiments. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the invention.

It is also within the spirit and scope of the invention to implement insoftware programming or of the steps, operations, methods, routines orportions thereof described herein, where such software programming orcode can be stored in a computer-readable medium and can be operated onby a processor to permit a computer to perform any of the steps,operations, methods, routines or portions thereof described herein. Theinvention may be implemented by using software programming or code inone or more general purpose digital computers, by using applicationspecific integrated circuits, programmable logic devices, fieldprogrammable gate arrays, optical, chemical, biological, quantum ornanoengineered systems, components and mechanisms may be used. Ingeneral, the functions of the invention can be achieved by any means asis known in the art. For example, distributed or networked systems,components and circuits can be used. In another example, communicationor transfer (or otherwise moving from one place to another) of data maybe wired, wireless, or by any other means.

A “computer-readable medium” may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, system ordevice. The computer readable medium can be, by way of example, only butnot by limitation, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, system, device,propagation medium, or computer memory. Such computer-readable mediumshall generally be machine readable and include software programming orcode that can be human readable (e.g., source code) or machine readable(e.g., object code).

A “processor” includes any, hardware system, mechanism or component thatprocesses data, signals or other information. A processor can include asystem with a general-purpose central processing unit, multipleprocessing units, dedicated circuitry for achieving functionality, orother systems. Processing need not be limited to a geographic location,or have temporal limitations. For example, a processor can perform itsfunctions in “real-time,” “offline,” in a “batch mode,” etc. Portions ofprocessing can be performed at different times and at differentlocations, by different (or the same) processing systems.

It will also be appreciated that one or more of the elements depicted inthe drawings/figures can also be implemented in a more separated orintegrated manner, or even removed or rendered as inoperable in certaincases, as is useful in accordance with a particular application.Additionally, any signal arrows in the drawings/figures should beconsidered only as exemplary, and not limiting, unless otherwisespecifically noted.

Furthermore, the term “or” as used herein is generally intended to mean“and/or” unless otherwise indicated. As used herein, a term preceded by“a” or “an” (and “the” when antecedent basis is “a” or “an”) includesboth singular and plural of such term (i.e., that the reference “a” or“an” clearly indicates only the singular or only the plural). Also, asused in the description herein, the meaning of “in” includes “in” and“on” unless the context clearly dictates otherwise.

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any component(s) thatmay cause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as a critical, required, or essentialfeature or component.

What is claimed is:
 1. A system for delivering content, comprising: aprocessor; a computer readable memory, comprising instructions for: asender module for executing on the processor in a cloud based computingenvironment to: receive content from a sending connector at a sendingdevice, wherein the sending connector is a plug-in of an application,the content is associated with a first destination identifier associatedwith a first delivery method, a transmission initiator of the contenthas sent the content to the first destination identifier according tothe first delivery method, and the first destination identifieridentifies a destination according to the first delivery method; and aforwarder module for executing on the processor in the cloud basedcomputing environment to: determine a second destination identifier anda second delivery method associated with the first destinationidentifier, without further involvement of the transmission initiator inthe determination; and deliver the content to the second destinationidentifier according to the second delivery method by providing alocation from which the content may be accessed and sending the locationto the second destination identifier; and a remote content access moduleconfigured to allow a user to access the content at the location.
 2. Thesystem of claim 1, wherein the second destination identifier is the sameas the first destination identifier.
 3. The system of claim 1, whereinthe second delivery method is the same as the first delivery method. 4.A transactional system, comprising: a transaction engine for sending andreceiving content and executing on a server, comprising: a senderconnector for receiving content from a sender device, wherein atransmission initiator of the content has sent the content to adestination identifier according to a delivery method; senderconfiguration information including: at least one delivery method fordelivery of the content to the transaction engine; a plurality ofdelivery parameters to control content delivery; and the destinationidentifier denoting a receipt address for a recipient according to thedelivery method; a forwarder for sending the content to the recipient,without further involvement of the transmission initiator in theforwarding; recipient configuration information including: at least onereceiver method for delivery of the content from the transaction engineto a recipient device; and a plurality of receiver parameters to furthercontrol content delivery; and a storage device for storing the content,the storage device in a predetermined geographic region and coupled tothe transaction engine, wherein the predetermined geographic region isconfigured by a sender, a transaction engine administrator, or arecipient.
 5. The transactional system of claim 4, wherein the senderconfiguration information is defined by a sender and received via thesender device.
 6. The transactional system of claim 4, wherein thedelivery parameters include at least one of: content type, regionalstorage information, validation information to validate the content,integration information for integrating the content for the recipient,and security information.
 7. The transactional system of claim 4,wherein the forwarder configuration information is defined by arecipient and received via the recipient device.
 8. The transactionalsystem of claim 4, wherein the forwarder parameters include at least oneof: content type, regional storage information, validation informationto validate the content, integration information for integrating thecontent for the recipient, and security information.
 9. Thetransactional system of claim 4, wherein the server is a plurality ofdistributed network servers, the servers under the control of a serviceentity enabling use of the transaction engine by a sender and arecipient over a network to send and receive the content.
 10. Thetransactional system of claim 4, wherein the predetermined geographicregion is based on security parameters for the content.
 11. Thetransactional system of claim 4, wherein the sender configurationinformation further includes a transmission identifier, the content isstored as a plurality of storage pieces on the storage device, and thestorage pieces are associated with the transmission identifier.
 12. Thetransactional system of claim 4, wherein the transaction engine furthercomprises a notification module for configuring notifications to atleast one of a sender and a recipient.
 13. The transactional system ofclaim 4, wherein the transaction engine is configured to delete thecontent on the storage device based on the elapse of a predeterminedamount of time the content is stored on the storage device.
 14. Acontent delivery system, comprising: a content delivery engine forsending and receiving content and executing on a server, comprising: asender connector for receiving content from a sender device, wherein atransmission initiator of the content has sent the content to adestination identifier according to a delivery method; senderconfiguration information including: at least one delivery method fordelivery of the content to the content delivery engine; and thedestination identifier denoting a receipt address for a recipientaccording to the delivery method; a forwarder for sending the content toa recipient, without further involvement of the transmission initiatorin the forwarding; recipient configuration information including: atleast one receiver method for delivery of the content from the contentdeliver engine to a recipient device; and a storage device for storingthe content, the storage device in a predetermined geographic region andcoupled to the transaction engine, wherein the predetermined geographicregion is configured by a sender, a transaction engine administrator, ora recipient, wherein the content delivery engine maps the receiptaddress to the at least one receiver method, the receiver methodincluding information for integrating the content into an applicationexecuting on the recipient device, the forwarder sending the contentaccording to the mapped receiver method.
 15. The system of claim 1,wherein the content is delivered with associated metadata.
 16. Thesystem of claim 1, wherein the forwarder module executes to delete thecontent after the expiration of a time period.
 17. The system of claim1, wherein the content includes content from an email client,SharePoint, an Oracle application, an SAP application, Lotus Notes, afax machine, a web page, or an enterprise resource planning (ERP)system.
 18. The system of claim 1, wherein the location includes aUniform Resource Locator (URL).
 19. The system of claim 18, wherein thelocation is provided by sending an email.